home *** CD-ROM | disk | FTP | other *** search
-
- CURRENT_MEETING_REPORT_
-
-
- Reported by James Davin/MIT
-
- SNMP NM Directorate Minutes
-
- Special Session
-
- These Minutes record statements made during an open session convened at
- the IETF meeting in Atlanta. These minutes are an accurate report of
- what was said as a concrete reference for future discussion; however, no
- statement reported here should be construed either as a consensus of
- those present or even as necessarily factually correct (in explicit
- content or in implicit assumptions).
-
- Chuck Davin (MIT) called the meeting to order and reviewed the purpose
- of the session as it had been announced in mailing list postings:
-
-
- From: "James R. (Chuck) Davin" <jrd@ptt.lcs.mit.edu>
- To: snmp-wg@nisc.nyser.net
- Subject: SNMP Directorate Mtg at Atlanta
- Date: Wed, 17 Jul 91 20:06:56 -0400
- Sender: jrd
-
-
-
- Agenda
-
- The SNMP Network Management Directorate session scheduled for the
- Atlanta IETF meeting will have as its goal the identification of
- concerns about functional deficiencies in the SNMP network management
- framework. The scope of the discussion will be lapses in the scope of
- extant management instrumentation and functional problems or
- deficiencies in the Internet SMI (RFC 1155; also RFC 1212) and the SNMP
- protocol (RFC 1157).
-
-
- o Instrumentation Scope
- o Structure of Management Information (RFC 1155; also RFC 1212)
- o Simple Network Management Protocol (RFC 1157)
-
-
- To keep the session productively focused, discussion will not extend to
- any identification or description of potential solutions.
-
- Participants are asked to have read relevant documents in advance of the
- session.
-
- Davin took pains to emphasize that the purpose of this meeting was to
- identify perceptions of functional deficiencies in the internet-
- standard network management framework and that discussion of potential
- solutions was not in order.
-
- 1
-
-
-
-
-
- Davin also stated that this meeting was a tentative, exploratory step in
- a process whose future course remains unclear. Regardless of the future
- course of any efforts to evolve the internet- standard network
- management framework, it would be useful even at the outset to begin to
- identify what problems might need addressing in any such future work.
- Davin reminded those present of the exceptional character of the meeting
- and that no one should draw any conclusions from this meeting about the
- content, process, venue, or schedule of any future work on the internet-
- standard network management framework.
-
- After this introduction, the floor was opened, and a succession of
- speakers addressed the meeting to articulate one or more perceived
- problems with the internet-standard NM framework.
-
- David Waitzman (BBN) identified the performance of SNMP in the retrieval
- of large amounts of tabular management information as being less than
- desirable. He cited as an example the task of retrieving the columns of
- a routing table for purposes of comparing its contents to an
- administratively determined configuration.
-
- Waitzman also stated that interoperability among SNMP systems may suffer
- owing to varying practice with respect to the creation and deletion of
- of MIB object instances.
-
- Waitzman also stated that MIB objects with mandatory status that were
- not universally implementable posed problems of interoperability, fault
- diagnosis, and ill-defined conformance posture.
-
- Waitzman also stated that it is difficult to map between the information
- models for OSI and SNMP network management. He characterized this
- problem as one of increased difficulty for MIB implementors and
- attributed it to a lack of coordination among standards bodies.
-
- Waitzman also stated that the level of granularity in SNMP authorization
- mechanisms was inadequate to realize certain policies.
-
- Lynn Monsanto (Sun Microsystems Incorporated) stated that his customers
- want to have confidence that significant network events will be reliably
- reported to a management station. He emphasized this point by noting a
- lack of defined MIBs for management stations. He also cited an example
- environment in a brokerage house that requires a very low mean time to
- detect errors.
-
- Monsanto stated that the framework was weak in its support for
- distributed atomic operations, e.g., to add a user account to multiple
- hosts but to back out of the operation under certain circumstances.
-
- Monsanto also stated that the SNMP SMI makes units of measurement for
- various instrumented quantities ambiguous. He pointed out that this
- makes mechanical interpretation of MIB objects by management stations
- difficult. In this context, he also cited the difficulty in displaying
- a new, unknown MIB object at a management station.
-
- Karl Auerbach (Sun Microsystems Incorporated) stated that the SNMP SMI
-
- 2
-
-
-
-
-
- does not afford support for representing large numbers. He cited the
- example of the number of bytes transmitted on an Ethernet interface in
- this connection. He also stated that the SNMP SMI was weak in its
- distinction between signed and unsigned quantities, offering as an
- example the difference between measurements of disk space and a bank
- account balance.
-
- Auerbach also stated that it is difficult for a management station to
- know how to display a retrieved physical address quantity. He said that
- this difficulty limits the range of network types that can be managed by
- SNMP.
-
- Auerbach also stated that the SNMP error status values confuse network
- operators. He cited the example of the readOnly status.
-
- Auerbach also stated that the use of ASN.1 encodings in the SNMP imposed
- an excessive computational burden on agent systems and that this burden
- is compounded by the emerging SNMP security proposals.
-
- Auerbach also stated that the atomic failure character of the SNMP Get
- operation complicates the implementation of management stations.
-
- Auerbach also stated that ``holes in the MIB'' owing to unimplemented
- MIB objects or access control policies cause both a performance problem
- and an efficiency problem for the internet-standard network management
- framework.
-
- Auerbach also stated that the retrieval of large amounts of tabular
- information via the SNMP was inefficient both in terms of bandwidth
- consumed and in packet processing overhead. He cited as examples the
- need to retrieve log files, large routing tables, and core image dumps
- using the SNMP.
-
- Auerbach also stated that the existence of MIB objects with optional
- status poses an interoperability problem. He stated that such objects
- also pose the problem that important management information may not be
- present when it is needed. He further cited in this connection the
- inefficiency of repolling when operations may fail owing to the absence
- of desired information. Auerbach stated that he personally likes
- optional status MIB objects but that, in reality, vendors do not observe
- the MIB group as the unit of conformance. In this context, he observed
- that a conceptual table in the MIB that currently comprised no
- conceptual rows was difficult to distinguish from a failure to implement
- the relevant MIB objects.
-
- John Cook (Chipcom Corporation) stated that the framework may lack a
- consistent way within the SNMP framework by which agents may document
- what MIB objects they support.
-
- Cook also identified a problem with the Ethernet MIB currently under
- discussion that it attempts to instrument both IEEE 802.3 and
- traditional Ethernet functionality.
-
- Karl Auerbach stated that the feedback afforded by a SNMP Set operation
-
- 3
-
-
-
-
-
- is weak and the attendant ambiguity requires that SNMP Sets be done in
- the blind. Thus, the results of a Set must be confirmed by a poll, and
- this requirement interferes with the need to perform management
- operations atomically.
-
- Auerbach also stated that the implementation of management stations is
- complicated by the lack of uniform practice with respect to creation and
- deletion of MIB object instances. In particular, the implementation of
- managers is complicated by lack of knowledge about what is required in
- the varbind list for SNMP Sets.
-
- Auerbach also stated that semantic relationships that affect ranges of
- acceptable values for MIB objects are not well-represented in the
- internet- standard network management framework with the result that
- implementation of management stations is more complicated. He cited the
- example that if an instance of the ifType MIB object has the value 5,
- then the value for the corresponding instance of the ifSpeed object can
- not be 10 Mb/s. He also said that constraints of this sort can
- transcend the scope of individual conceptual tables.
-
- Auerbach also stated that the lack of a MIB representation for maximum
- acceptable SNMP PDU sizes reduces the efficiency of management.
-
- Fred Baker (ACC) stated that the failure to implement mandatory MIB
- objects hurts implementors of proxy agents that have made good faith
- efforts to conform to MIB standards. Because existing standards are not
- clear on the conformance requirements for proxy agents, such agents may
- themselves be inappropriately judged as nonconformant when they proxy
- for a deficient agent.
-
- John Cook stated that management stations need more information than is
- currently represented in the internet-standard network management
- framework in order to do a good job of managing the network. He cited
- the lack of a common representation for individual objects and
- structures of those objects that is oriented to the needs of management
- stations.
-
- Cook also stated that the framework may be lacking a way to distribute
- ``human information'' to management stations -- for example, useful
- human-readable text, or textual tags for enumerated values.
-
- Karl Auerbach stated that the internet-standard framework can complicate
- the configuration of a management station: constructing ``smart''
- management applications may be difficult because the framework lacks a
- dynamic, mechanical way of finding out what is in a managed device.
-
- Auerbach also stated that textual ambiguities in the standard
- specifications degrades interoperability. He cited as an example of
- this problem the phrase ``as if simultaneously.''
-
- John Saperia (Digital Equipment Corporation) stated that in the existing
- framework it was difficult to associate information collected over time
- with MIB structures that may change over time. He cited the example
- that, although statistics may be collected over time about several
-
- 4
-
-
-
-
-
- network interfaces, the representation of such interfaces in the MIB may
- itself change over time as the result of management operations.
-
- David Waitzman stated that implementation of a management station is
- complicated by the possibility of receiving a reference to an
- unrecognized MIB object in the varbind list of a SNMP trap PDU. In this
- context, Waitzman noted a lack of any mechanism in the framework to
- obtain information on how to display an unknown MIB object.
-
- Waitzman also stated that the representation of the IP routing table in
- MIB-2 does not support multiple routes to a single destination.
-
- Karl Auerbach stated that the scope of ASN.1 syntax that is legal in
- Concise MIB expressions is not made clear in the relevant standards.
-
- Bob Stewart (Xyplex, Incorporated) stated that the cost of agent
- implementation for MIB objects is a problem with the current framework.
- Stewart stated that limitations on what agents need to do is important
- and that too much is expected of managed agents. He also stated that
- providing minimal management information in agents is a big job.
-
- Karl Auerbach stated that interoperability suffers in the current
- framework owing to a lack of a common communication mechanism between
- ``head agents'' and ``subordinate agents.''
-
- Anil Rijsinghani (Digital Equipment Corporation) stated that, because
- the IEEE allows individual objects to be optional, the translation of
- network management definitions from IEEE into the SNMP idiom is
- complicated.
-
- Rijsinghani also stated that the framework lacks rules of thumb for
- translating IEEE conformance posture into the SNMP idiom. (Marshall
- Rose of Dover Beach Consulting interjected a reference to Appendix A of
- RFC 1212 at this point in the proceedings.)
-
- Rijsinghani also stated that the IETF process for developing SNMP
- standards produced a level of volatility that is incompatible with
- gaining essential implementation experience.
-
- Karl Auerbach stated that the semantic context of a SNMP Set operation
- (particularly the relation of one MIB object to another) may be
- ambiguous in the current framework. He cited the example of a MIB
- object whose semantics are ``open bomb bay doors'' and a MIB object
- whose semantics are ``drop bombs.'' He pointed out the importance of
- temporal sequencing in operations on these two objects.
-
- Bob Stewart stated that the process by which MIBs are developed may be
- inconsistent in its discouraging of vendors against shipping
- experimental MIBs while at the same time enjoining vendors to experiment
- to benefit the community. He stated that companies don't want to do
- experiments that don't ship in products but that companies will ship
- experiments and assume the risk that entails. Stewart cited as a
- problem in the framework that the intended use of the experimental
- branch of the MIB namespace is not clearly articulated.
-
- 5
-
-
-
-
-
- Karl Auerbach stated that a problem with the current framework is its
- excessive use of polling. He stated that a deficiency of the framework
- is the lack of a way to generate traps at the discretion of a manager,
- in order that knowledge about a serial scenario and its causal structure
- may be profitably applied.
-
- David Perkins (Synoptics, Incorporated) stated that a weakness of the
- internet- standard network management framework was the difficulty in
- understanding it adequately to do an implementation. He stated that the
- specifications could be clearer, particularly in the areas of proxy
- operations and the function of SNMP communities.
-
- Perkins also stated that a problem with the current framework is that
- the heritage of RFC 1155 as a dual SMI for both CMOT and SNMP confuses
- some readers owing to now-extraneous provisions.
-
- Perkins also stated that a problem with the framework is its lack of a
- MIB for instrumenting the function of the BOOTP protocol and the process
- of booting in general. He cited in this context the special problems of
- devices that incorporate flash EPROM technologies.
-
- Perkins also stated that the current framework suffered from a model of
- network interfaces (as captured in the ifTable of MIB 2) that is
- confusing and difficult to understand.
-
- Perkins also stated that the current notation for defining MIBs makes it
- hard for people to learn how to write MIBs. In this context, he stated
- that the Concise MIB notation should be even more concise. He also said
- that the framework lacked notational support for capturing of defined
- object identifiers by management stations.
-
- Lynn Monsanto stated that interoperability suffers because the framework
- lacks support for management stations to interact easily with new or
- unfamiliar devices. He cited the example of the new class of devices
- that implement the RMON MIB. He stated that the framework comprises no
- algorithms or mechanical notations for communicating the complex
- semantics of such MIBs to the management station.
-
- Monsanto also stated that the framework may engender confusion among its
- users because the notation for building instance identifiers may be
- confusing, particularly for ``messy'' tabular constructs.
-
- Karen Robertson (Concord Communications) stated that interoperability
- suffers owing to the lack of a consistent mechanism for configuring and
- using SNMP proxy.
-
- Robertson also stated that the effectiveness of the framework in certain
- contexts may be compromised by the lack of a common mechanism to recover
- from timeouts. She cited a problem raised in the Internet Accounting
- Working Group that concerned the loss of valuable information when the
- specified polling interval may be too short.
-
- Robertson also stated that the framework makes the definition of new MIB
- specifications difficult owing to the lack of provision for defining
-
- 6
-
-
-
-
-
- ASN.1 subtypes from existing SMI types. She cited the example of
- subrange types defined from the existing Guage type.
-
- Cheryl Krupzak (herself) stated that interoperability and efficiency
- suffer for want of a common mechanism for supporting multiple SNMP
- agents on the same platform.
-
- Krupzak also stated that interoperability and efficiency suffer from
- variations in practice regarding constraints on the minimal set of
- varbinds required in a SNMP Set PDU that is to instantiate a conceptual
- row in the MIB.
-
- Krupzak also stated that interoperability and efficiency suffer for want
- of a common strategy for marking the deletion of conceptual rows from
- the MIB.
-
- David Waitzman stated that the framework may be confusing to
- implementors in the conventions surrounding the SNMP Trap PDU. Waitzman
- cited the names of the fields in the Trap PDU, the semantics of trap
- types, and the operation of trap mechanisms in general as possible
- points of confusion among implementors.
-
- Keith McCloghrie (Hughes LAN Systems) stated that a weakness of the
- current framework was that it did not facilitate development of
- management applications because current MIB conformance postures admit
- too much optionality and assure too little commonality in what MIB
- objects are actually available for applications to use.
-
- McCloghrie stated that the current framework does not foster
- interoperability or facilitate management station implementation because
- it lacks a common notation for documenting degrees of conformance by an
- implementation. He cited the example of an agent that implements a
- subset of MIB 2 and observed that there is no common way of documenting
- that subset.
-
- McCloghrie also stated that the framework was limited in the range of
- MIBs it could generate owing to the lack of a way to define structures
- of traditional MIB objects that need not be manipulated individually.
-
- Karl Auerbach stated that interoperability and global management suffer
- owing to the lack of a tough requirement on the out-of-the-box state of
- every device. He cited the need to characterize new or unfamiliar
- devices and stated the desirability of requiring that the system group
- of MIB 2 be required to be available for query on every device.
-
- Frank Kastenholz (Clearpoint Research) that the use of SNMP management
- in non-IP networks may suffer owing to the inclusion of a NetworkAddress
- value in the Trap PDU.
-
- Bob Stewart stated that a concern for agent implementations was that the
- framework did not explicitly provide for transient MIB objects
- exclusively to support effective use of varbind lists in Trap messages.
- He observed that although the contents of a Trap varbind list is
- properly derived from MIB objects, the cost entailed by making such
-
- 7
-
-
-
-
-
- objects constantly available may not be justified in some cases.
-
- Frank Kastenholz stated that the implementation of mangement stations is
- complicated by the lack of a common mechanism for automatic discovery of
- network devices.
-
- Jeff Case (University of Tennessee, Knoxville, on behalf of Unni
- Warrier, not present) stated that effective management suffered for want
- of more intensive transport mechanisms that provide reliable
- communication.
-
- Bob Stewart stated that the range of widely deployed SNMP configurations
- may be limited by the lack of explicit statement in the standards that a
- single-system may realize both agent and manager roles.
-
- Mark Kepke (Hewlett-Packard) stated that a weakness of the current
- framework is the difficulty experienced by vendors in developing private
- MIB specifications.
-
- Kepke also stated that interoperability may suffer from the want of a
- common mechanism for configuring the destinations of Trap PDUs.
-
- Kepke also stated that interoperability may suffer owing to confusion
- about the use of DEFVAL clauses and their role in object instantiation.
-
- Kepke also stated that implementation of management stations was
- complicated by the lack of a common notation or mechanism for
- correlating semantically related constructs in the MIB. He cited the
- example of exploiting the analogous structure and content of the ifTable
- and the various tables of the Ethernet MIB.
-
- Frank Kastenholz stated that the development of standard MIB
- specifications may be impeded by confusion about IAB policy and
- procedures for MIB acceptance.
-
- Jeff Case (on behalf of Unni Warrier, not present) stated that the
- efficiency of the internet- standard network management framework
- suffers from the use of ASN.1 encoding and that, accordingly, a new
- transfer syntax is desirable.
-
- John Cook stated that implementation of the SNMP is complicated by its
- use of special security mechanisms and that implementation would be
- facilitated by the use of a common authentication technology (CAT) in
- SNMP.
-
- David Waitzman stated that the effectiveness of the framework may suffer
- for want of a LSSR or SSSR mechanism for use in the transmission of Trap
- PDUs.
-
- Jeff Case (on behalf of Unni Warrier, not present) stated that a
- weakness of the framework is its disregard for international standards
- and that compatibility with CMIP should be an important goal for the
- future.
-
-
- 8
-
-
-
-
-
- At this point, Chuck Davin adjourned the session, as the time allotted
- for the meeting had elapsed.
-
- Attendees
-
- Karl Auerbach karl@eng.sun.com
- James Barnes barnes@xylogics.com
- Steve Bostock steveb@novell.com
- John Burruss jburruss@wellfleet.com
- Jeffrey Case case@cs.utk.edu
- John Cook cook@chipcom.com
- Kurt Dobbins dobbins@ctron.com
- Shari Galitzer shari@gateway.mitre.org
- Shawn Gallagher gallagher@quiver.enet.dec.com
- Phillip Hasse phasse@honchuca-emh8.army.mil
- Mark Hoerth mark_hoerth@hp0400.desk.hp.com
- Ron Jacoby rj@sgi.com
- Ken Jones konkord!ksj@uunet.uu.net
- Frank Kastenholz kasten@europa.clearpoint.com
- Manu Kaycee kaycee@ctron.com
- Mark Kepke mak@cnd.hp.com
- Kenneth Key key@cs.utk.edu
- Christopher Kolb kolb@psi.com
- Bobby Krupczak rdk@cc.gatech.edu
- Cheryl Krupczak cheryl@cc.gatech.edu
- heryl Krupczak cheryl@cc.gatech.edu
- Tim Lee-Thorp ngc!tim@uunet.uu.net
- Keith McCloghrie kzm@hls.com
- Robert Meierhofer robert@cnt.mn.org
- Lynn Monsanto monsanto@sun.com
- David Perkins dperkins@synoptics.com
- Anil Rijsinghani anil@levers.enet.dec.com
- Michael Ritter mwritter@applelink.apple.com
- Kary Robertson kr@concord.com
- Marshall Rose mrose@dbc.mtview.ca.us
- Jonathan Saperia saperia@tcpjon.enet.dec.com
- Mark Schaefer schaefer@davidsys.com
- John Seligson johns@ultra.com
- Timon Sloane peernet!timon@uunet.uu.net
- Lance Sprung sprung@sys.smc.com
- Bob Stewart rlstewart@eng.xyplex.com
- Bruce Taber taber@interlan.com
- Dean Throop throop@dg-rtp.dg.com
- Maurice Turcotte dnmrt@rm1.uucp
- David Waitzman djw@bbn.com
- Steven Waldbusser waldbusser@andrew.cmu.edu
- Drew Wansley dwansley@ccgate.ColumbiaSC.NCR.COM
- Preston Wilson preston@i88.isc.com
- Wengyik Yeong yeongw@psi.com
- Joseph Zur fibrontics!zur@uunet.uu.net
- Peter de Vries peter@wco.ftp.com
-
-
-
- 9
-